Typically, a network security system treats a new version of a previously characterized and/or processed executable file (.exe) as a new or unknown entity. One reason is that a hash or other computation performed on the file commonly is used to detect changes in an executable file, since if malicious code were added to an executable the new code would be detected. Of course, it is also possible, and in some contexts considerably more likely, that a software patch (e.g., security or other update) or a new version has been installed (e.g., downloaded), and that the patched (or new) version does not represent any greater or lesser threat than the original. Often, a patch or new version only slightly modifies the overall structure and operation of the executable; this is especially true of large software applications such as word processing, spreadsheet, operating system, instant messaging, and other programs. The major functionality of such programs typically remains in place, and patches and new versions often represent only minor changes and/or additions to the pre-existing functionality and program structure.
However, in an all-or-nothing approach to security any detected change results in a patched or new version of a previously trusted (or not trusted) executable triggering the same response as entirely new or unknown code. For example, an outbound firewall that previously prompted a user for and received user input indicating whether an original version of an executable should be allowed to send an outbound communication in a typical case would have to prompt the user anew upon execution of such an operation by a patched or new version of the same executable, even if the portion of the executable that is being executing and is attempting to send the outbound communication is the same as the corresponding portion of the original executable (e.g., that portion of code was not affected by the patch). Depending on the circumstances, including user preferences and other user requirements, the number of executables installed and run on the protected host and how often they undergo legitimate change, etc., it may be highly undesirable to interrupt operations to prompt a user to indicate the extent to which an executable file should be trusted (e.g., permitted) to perform certain actions.
Therefore, there is a need for a way to ensure that unchanged portions of an executable file that have already been characterized for security purposes continue to be afforded the same level of trust subsequent to installation of a patch or new version that does not change such portions, and to ensure that new or changed portions are properly characterized.